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ABSTRACT 


Technological complexities of current ground combat systems require advanced 
maintenance methods to keep the fleet in a state of operational readiness. Currently, 
maintenance personnel use paper Technical Manuals (TM) that are cumbersome and not 
easily transportable or updated in the field. This thesis proposes using the latest 
technology to support maintainers in the field or depot by integrating the TMs with the 
onboard diagnostics Built-In-Test (BIT) and Fault Isolation Test (FIT) of the vehicle, to 
provide the maintainer with an improved diagnostics tool to expedite troubleshooting 
analysis. 

This will be accomplished by connecting the vehicle, using the vehicle’s 1553 
multiplex bus, with the Graphical User Interface (GUI) of an Intelligent Maintenance Aid 
(IMA). The IMA will use Troubleshooting Procedure (TP) codes generated during BIT 
and FIT testing. Using the information provided by these TP codes, through the IMA 
GUI, information from the technical manuals will be displayed to aid the maintainers in 
their diagnostic work. 

The results of this thesis will serve as a baseline for further research and will be 
presented to the program management office for combat systems (PM-CS) for further 
consideration and development. 
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I. INTRODUCTION 


A. BACKGROUND INFORMATION 

As the Army improves the effectiveness of its forces with technology, the 
complexity of ground vehicle weapon systems continues to increase. These systems 
contain a multitude of Vetronics (Vehicle Electronics) and have become increasingly 
difficult to maintain and repair with traditional Army personnel, test equipment and 
technical documentation. Maintaining these systems requires highly trained personnel 
with in-depth knowledge of embedded systems. To meet the maintenance and repair 
demands of these systems, the Army must rely more on technology and less on humans. 
Future ground vehicle weapon systems must be designed to self-diagnose and provide 
test and maintenance interfaces to external test equipment. Integrated maintenance and 
repair capabilities with advanced technologies and Artificial Intelligence (AI) will 
improve the overall effectiveness of the force. 

These solutions, however, do not address fielded vehicle systems. Presently, 
repairs are made, with the help of paper Technical Manuals (TM), at the depot level 
maintenance. When these systems were conceived it was not cost or technologically 
feasible to provide comprehensive embedded test and maintenance capabilities. Most 
systems were constrained to test connectors that provided limited test and diagnostic 
capability. 

However, with the advent of the Personal Computer (PC), a powerful tool 
becomes available that can be leveraged for fielded Army systems even though it was not 
envisioned during development of these older systems. Most fielded ground vehicle 
systems contain standard data interfaces such as 1553, CAN, RS232 and Ethernet; the 
Army can exploit this and utilize the PC to extract data via these interfaces. Most 
systems with these types of interfaces provide some level of Built-In Test (BIT) and/or 
Fault Isolation Test (FIT) capability. The PC will be configured to monitor the above 
tests and provide status. With this captured information, the PC will analyze the 
diagnostic data and provide troubleshooting and repair information to maintenance 
personnel. The platform, called the Soldier Portable On-Site Repair Tool (SPORT), 
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primarily functions as a software downloader with no diagnostic/prognostic capability 
(Figure 1). The SPORT’s inability to provide a portable capability (in addition to 
performing downloader duties) to perform diagnostie tasks severely hampers the 
maintenanee operator’s ability to keep their vehieles in constant state of mission 
readiness. 


SPORT or Similar hpst 


On-line, 
Hyper-linked 
Tech manuals 


Maintenance AlHs^ 
(digital video clips, 


Virtual system models) 



Combat platform 
I/F 



Legacy, Interim & Future Combat Platforms 


Figure 1. SPORT PC 

B. STATEMENT OF PROBLEM 

Currently, when performing on-board vehicle diagnostics, maintenance personnel 

rely on Technical Manuals (TM) to provide repair information. These TMs are usually 

available only to Depot repair facilities; this greatly reduees/impairs the ability to make 

repairs in the field, especially during combat battlefield eonditions. For example, the 

M1A2 Main Battle Tank is an intelligent system containing multiple microprocessors, 

which have Built In Test (BIT) and Fault Isolation Test (FIT) capabilities. These tests 

report failures to the user interfaees on the Commander’s Integrated Display (CID), 
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Driver’s Integrated Display (DID), and Gunner’s Control and Display Panel (GCDP). 
Failures are reported with Troubleshooting Procedure (TP) numbers that are cross- 
referenced with the TMs to isolate and repair the failed system components. The physical 
TMs are cumbersome to use and significantly add to the time required for diagnosing and 
repairing a vehicle system. The TMs also are updated on a scheduled basis with change 
notices and, if not updated regularly, can lead to misdiagnosis of the problem and provide 
faulty resolutions. 

C. PROPOSED SOLUTION 

This thesis will investigate a portable intelligent solution for the problem stated 
above. Providing an Intelligent Maintenance Aid (IMA) that interfaces with ground 
vehicle weapon systems will satisfy most of the Army’s maintenance requirements and 
will surpass current maintenance and diagnostic capabilities. This will be achieved by 
providing the user with an interface (I/F) to the system being evaluated (in our case, the 
M1A2 tank, but it could be any ground platform as the concept diagram below depicts). 
The native data bus will use one of the following standard protocols: 1553, CAN, RS232 
and Ethernet to communicate to a SPORT or similar host. Once connected, the user will 
access IMA software to begin diagnosing the system under repair (see Figure 2 below). 
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Figure 2. IMA Screen Shot 

The basic IMA system will automate the use of TMs. The approach will be to 
utilize the current TMs that have been captured electronically in Adobe Acrobat. The 
electronic TMs for the Hull and Turret will reside on the hard drive of the computer that 
hosts the IMA. We will develop algorithms to search the documents for the TP numbers 
that are reported by the M1A2 system. 
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D. THESIS ORGANIZATION 

This chapter gives a brief description of the problem addressed by the thesis and 
discusses a solution to this problem, using the IMA to aid maintenance personnel. It also 
provides a high level introduction into the on-board diagnostics of the M1A2 Main Battle 
tank. 

Chapter II presents an overview of the Ml A2 hardware and software architecture. 
It explains how the M1A2 tank system’s computational components are connected via a 
MIL-STD-1553 data bus. The chapter also introduces a primer into the operational 
characteristics of the MIL-STD-1553 data bus. 

Chapter III contains the requirements and design for the Intelligent Maintenance 
Aid (IMA). The design includes several elements of the Universal Modeling Language 
(UML): Use Case diagrams. System Context Diagram, and a Conceptual model. 

Chapter IV consists of a detailed discussion of the proposed software architecture 
of the IMA project. 

Chapter V contains the test and evaluation of the IMA project. 

Chapter VI discusses the lessons learned and draws a conclusion. 
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II. ABRAMS MAIN BATTLE TANK (AN OVERVIEW) 


A. M1A2 SYSTEM ARCHITECTURE 

The M1A2 tank system architecture provides for the interconnection of a series of 
distributed Line Replaceable Units (LRUs) via a power distribution and data distribution 
network. The M1A2 system architecture is based on a dual redundant data and utility bus 
design. The primary computational system components are interconnected via a Mil-Std 
1553B Data Bus that provides digital communication between tank components. The 
utility bus is used for power management and provides the digital communication 
required to control power at various system components and loads. The hull and turret 
system components are separated via a slip ring that provides for a continual, 
uninterrupted, reliable connection for electrical circuits as well as air and hydraulics. The 
baseline M1A2 system architecture is depicted below in Figure 3. 
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Figure 3. M1A2 System Diagram 
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The M1A2 system diagram is intended to identify the primary computational 
system elements and their interconnections and is not intended to identify the complete 
system architecture. 


B. M1A2 HARDWARE ARCHITECTURE 

The M1A2 is comprised of a series of primarily VME based LRUs, which are 
functionally allocated to perform various system tasks, described below. 


LRU 

Description 

CITY 

The Commander’s Independent Thermal Viewer (CITV) provides 
the tank commander with an independent stabilized thermal sight 
with continuous 360-degree surveillance. The CITV also provides 
for hunter/killer capability, selected sector autoscan, search and gun 
line of sight modes, and a backup firing/sight system. 

FCEU 

The Fire Control Electronics Unit (FCEU) provides for fire control 
system integration through stabilization control, weapon firing 
control, operating state control, ballistic offset insertion, and ballistic 
parameter collection. 

GPS 

The Gunner’s Primary Sight (GPS) is coordinated with the FCEU in 
order to provide for gun LOS, gun control, thermal/optics control 
and range data. 

H/TEU 

The Hull/Turret Electronics Unit (H/TEU) perform various primary 
and backup system control functions listed below. 

CID 

The Commander’s Integrated Display (CID) provides for all 
operator Command, Control, and Communication’s functions. This 
includes IVIS/RIU and SINCGARS operation as well as the 
preparation and disposition of tactical information. In addition, the 
CID also provides for the controls of the CITV and the display of 
both CITV imagery and system BIT status. 

RIU 

The Radio Interface Unit (RIU) provides an interface between the 
Single Channel Ground Airborne Radio System (SINCGARS) and 
the core vehicle electronics. The RIU provides for control of the 
SINCGARS transmitter, receiver, and crypto functions, manages the 
radio net, processes and manages radio message packets, 
algorithmically corrects transmission errors, and performs built in 
test. 

GCDP 

The Gunner’s Control and Display Panel provides for the selection 
of ammo sub designate for the currently selected round, allows 
manual entry of sensor inputs for ballistic computations, provides 
GCDP panel built in test, and provides IFTE, CEE, and DSESTS 
test interface. 
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LRU 

Description 

DECU 

The Digital Electronics Control Unit (DECU) provides for the 
primary interaction with and control of the vehicle engine. The 

EAJ6 DECU provides a 1553 system interface, which is utilized for 
systems interfacing and application downloading via the software 
loader verifier. 

POS/NAV 

The Position Navigation Unit (POS/NAV) provides the 
commander/driver navigation functions with tank heading and 
position data. In addition, the POS/NAV unit provides tank azimuth 
angular rate, tank pitch and roll angles for dynamic cant generation, 
and allows startup with self-initialization, stored heading, or 
manually input heading. 

HPDU 

The Hull Power Distribution Unit (HPDU) controls power to the 
Remote Switching Modules (RSMs), controls power to the Power 
Control Modules (PCMs), provides power and switching to localized 
loads, houses the vehicle NATO slave receptacle, and controls 
master power via the primary power interrupter. 

DID 

The Driver’s Integrated Display (DID) provides engine and vehicle 
automotive command, engine control unit display, vehicle heading 
and steer to functions, drivers built in test. 


Table 1. Primary and Backup Systems 


The CID, DID, GCDP, RIU, H/TEU, FCEU, and POS/NAV LRUs form the core 
system computing environment for the M1A2 baseline. 

The M1A2 system is comprised of additional components, not identified here. 
Most of these components are hardware-based units providing additional system 
inputs/output data and control. These components include position sensors, 
ballistic/environment sensors, analog input modules, remote switching modules, and 
operator handles/switch panels. 


C. M1A2 SOFTWARE ARCHITECTURE 

The M1A2 software is partitioned to functionally match the M1A2 system design. 
The software is subdivided into Computer Software Configuration Items (CSCIs), which 
correspond to each MIA2 system LRU capable of performing computational data 
processing. A CSCI is further divided into Computer Software Components (CSCs), 
which map to major system functions and are resident on the various processors 
contained within each system LRU. The CSCs are further subdivided into Computer 
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Software Units (CSUs), which implement required CSC functionality. The software 
functional mapping to M1A2 system LRUs for the baseline M1A2 is depicted below in 
Figure 4 (TARDEC 2002). 



Figure 4. M1A2 Functional Software Diagram 


The M1A2 baseline software was primarily programmed utilizing Mil-Std 1815, 
the Ada Programming Language. MC68020 assembly language and ANSI C were also 
used. 

D. MIL-STD-1553 DIGITAL TIME DIVISON COMMAND/RESPONSE 
MULTIPLEX DATA BUS 

1. Hardware Description 

The 1553 MUX Bus uses a dual-redundant bus configuration (A and B). Each 
bus uses a 78-Ohm twisted, shielded, pair cable with 78 Ohm terminators. Terminal 
equipment is transformer isolated (TARDEC 2002). 
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2. Protocol Description 

All message transfers are twenty bit-time events at 1 MHz. The first three bits are 
synchronization, the next 16 bits are message data content, and the last bit is parity. 


1 so 

SI 

S2 
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11 

12 

13 

14 

15 

P 1 


The synchronization waveform for the Command and Status Words is an invalid 
Manchester of three bits duration: positive for IVi bit times and negative for IVi bit times. 
The synchronization waveform for Data Words is inverted. The bit parity for all words 
will be an "Odd Ones" on the 16 data bits. 



Data Bit Word Sync Data Bit Data Bit Word Sync Data Bit 

3. 1553 Data Bus Message Content 

The data code is Manchester II bi-phase. A logic one will be transmitted as a 
bipolar coded signal of 1/0 (i.e., a positive pulse followed by a negative pulse). A logic 
zero will be a bipolar coded signal of 0/1 (i.e., a negative pulse followed by a positive 
pulse). 

Bit values of the data content of each message will be from MSB to LSB, in the 
order received. 
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4. 1553 Data Bus Command Word 

The data content of the Command Word generated by the Bus Controller (BC) to 
the Remote Terminal (RT) has the RT address in the upper (most significant) five bits, 
followed by the Transmit/Receive bit, the five-bit message sub address/mode field, and 
the five-bit data word count/mode code field. 


15 14 13 12 11 

10 

9 8 7 6 5 

4 3 2 1 0 


Remote Terminal Address 

TR 

Message Sub address/Mode 

Data Word Count/Mode 
Code 


No Data Words follow the Command Word if the Transmit/Receive bit is set 
(Transmit). Bits five through nine indicate either a message sub address (“00001” 
through “11110”) or flag a mode code in bits zero through four (“00000” or “11111”). If 
a receive message sub address is indicated, a data word count (“00001” through “11111”, 
and “00000” for 32) appears in bits zero through four. If a mode command is indicated, 
the RT bus terminal hardware traps it and responds appropriately. 

The data content of the Data Words which accompany the Command Word when 
the Transmit/Receive bit is reset (Receive) have the appropriate content for that message 
as described in Data Packet Specifications Volume 1 through 11, DP-SA15132 Data 
Packet Specifications for M1A2 Main Battle Tank. 

5. 1553 Data Bus Status Word 

The Status Word from the RT to the BC has the RT address in the upper five bits, 
the Message Error bit in 10, The Instrumentation bit in nine, the Service Request bit in 
eight. The Broadcast Command Received bit in four, the Busy bit in three, the Subsystem 
Flag in two, the Dynamic Bus Control Acceptance bit in one, and the Terminal Flag in 
zero. Bits nine, five through seven, three, and one will be logic zero as these bits are not 
currently utilized. 
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The Message Error bit is set by the RT after a Command Word with an invalid 
message sub address and Transmit/Receive combination, or if a receive message is short 
of its Data Word count, failed word parity validation, has improperly timed data 
synchronization, or has non-contiguous data. If the Message Error bit is set, it is cleared 
for the next message, barring subsequent errors. The Instrumentation bit is undefined. 
The Service Request bit is set by the RT to initiate a transmit or receive transaction. The 
Broadcast Command Received bit is set when the preceding valid command is a 
broadcast command. The Broadcast Command Received bit is reset when the next valid 
command is received, except in the cases of a transmit status word and transmit last 
command. The Busy bit is set by the RT when no further messages can be processed 
until the busy condition is cleared. The Subsystem Flag is set to when a fatal operating 
fault occurs in the RT. The Dynamic Bus Control Acceptance bit is used by alternate 
BC’s only. The Terminal Flag bit is set by the RT if the Message Error, Service Request, 
or Busy bits are set. The Terminal Flag is set for a fatal operating fault condition in the 
RT bus terminal hardware. 

6. 1553 Data Bus Data Word with Status Word 

The data content of the Data Words which accompany the Status Word, 
regardless of the Service Request bit setting, when the preceding Command Word was a 
transmit command will have the appropriate content for that message. 

The data content of the Data Word which accompanies the Status Word when the 
Service Request bit is set and the preceding Command Word was not a transmit 
command will have zeros in the upper five bits, the Transmit/Receive bit in 10, the five- 
bit message sub address field in five through nine, and the five-bit data word count field 
in zero through four. This status response conformation is used only when an RT 
requires an exception, rather than periodic servicing. 
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7. 1553 Data Bus Message Transfer 

Inter-message gap and RT response times depicted are consistent with the 
requirements of MIL-STD-1553B. 
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The BC provides a minimum gap time of four microseconds between messages. 
The RT responds to a valid Command Word within a period of four to 12 microseconds. 
The minimum wait time between the last Data Word of a message transmitted by the BC 
and the receipt of a Status Word generated by the RT is 14 microseconds. 

8. 1553 Data Bus BC to RT Sequence 

In the BC to RT transfer sequence, the BC transmits a Command Word with its 
Transmit/Receive bit reset to indicate the RT will receive. The Command Word is 
followed by a sequence of one to 32 Data Words generated by the BC. The Command 
and Data Words are transmitted in a contiguous fashion with no interword gaps. The RT 
responds with a Status Word. 
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9. 


1553 Data Bus RT to BC Sequence 
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In the RT to BC transfer sequence, the BC transmits a Command Word with its 
Transmit/Receive bit set to indicate the RT will transmit. The RT responds with a Status 
Word followed by a sequence of one to 32 Data Words generated by the RT. The Status 
and Data Words are transmitted in a contiguous fashion with no interword gaps. 

10. 1553 Data Bus RT to RT Sequence 
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In the RT to RT transfer sequence, the BC transmits contiguously two Command 
Words, one with the Transmit/Receive bit reset to indicate the receiving RT and one with 
the Transmit/Receive bit set to indicate the transmitting RT. The Command Words are 
followed by a sequence of a Status Word and one to 32 Data Words generated by the 
transmitting RT. The Status and Data Words are transmitted in a contiguous fashion with 
no interword gaps. The receiving RT responds with a Status Word. 
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III. REQUIREMENTS AND SPECIFICATION 


A. REQUIREMENTS FOR IMA 

This section specifies the requirements that were used to develop the IMA 
prototype, a real time diagnostics tool for repairing ground combat systems. The system 
was designed to provide the vehicle maintainer an accurate and reliable means to 
diagnose and repair the vehicle, using the vehicle’s own on board diagnostics capability 
in conjunction with the technical manuals (document lookup capability) and an easy to 
use Graphical User Interface (GUI). The system also includes additional software and 
hardware interfaces from SBS Technologies for the 1553 Data bus to provide remote 
terminal, bus controller emulation and interface to the SPORT or equivalent computer 
that hosts the IMA as shown in Figure 5 below. 



Figure 5. IMA Interfacing with the Ml A2 tank 

The IMA will be operating in an environment with the real TEU (bus controller) 
and real H/TEU (Back-up Bus controller). 
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1. System Goals 

The IMA system shall be required to provide real-time access to 
technical/maintenance documentation enabling the user (maintenance personnel or 
engineers) for improved tum-around/de-bug time for repairs. The goals of the IMA are 
(1) to provide the user with rapid on-site repairs and (2) reduce cost of performing 
Combat Sustainment Support (CSS) without reducing war fighting capability or 
readiness. 

The IMA is a semi-autonomous system capable of functioning for extended 
periods of time with minimal maintenance support. The IMA shall be provided in a C -l-l- 
runtime-software package and Windows development environment. 

2. Assumptions and Dependencies 

The following assumptions and dependencies have been defined in order to 
simplify the development of the IMA: 

• The IMA shall fully support all known/used data bus configurations. 

• The IMA must use current Soldier Portable On-Board Repair Tool 
(SPORT or equivalent computer) platform as not to increase of 
development costs. 

3. Requirements/Function Assumptions 

• The IMA shall be developed on/for Windows based platforms. 

• C-i-i- shall be used in the development of Intelligent Maintenance Aid. 

• No special tools or test measurement device equipment are 
necessary/required. 

• The IMA can be operational 24 hours a day provided the SPORT or 
equivalent computer device is powered by an AC power source. 
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B. SYSTEM FUNCTIONS 

1. Required States and Modes 

The system shall be ready to operate at all times. The IMA provides for two 
modes of operation; test mode or look-up mode. Test mode provides access to vehicle 
system level BIT and FIT diagnostics operations through data bus communications. 
Look-up mode provides access to the on board technical manuals for reference. 

2. System Capability Requirements 

a. User Input 

The system shall be capable of accepting user input from buttons located 
either at the internal or the external keyboard on the SPORT or equivalent computer. 
Presentation of user input requests shall be done through a Graphical User Interface 
(GUI) used on the SPORT or equivalent computer. 

b. Provide User Feedback 

The system shall be capable of providing appropriate feedback to the user 
through a Graphical User Interface (GUI) used on SPORT or equivalent computer. 

c. System Response 

The system shall be capable at a minimum, of starting and stopping on 
desired selection(s). 

d. Communication Coordination 

The IMA system will efficiently coordinate communication between the 
SPORT or equivalent computer and the vehicle under test by use of data bus 
communication (i.e., 1553, RS-232, etc.). 


19 



Ref# 

Function 

Thesis 

Para.Ref. 

Category 

Use Case 

Association 

R1 

Rl.l 

Start SPORT or equivalent 
computer 

Enter Log-In & Password 

III.B.2.a 

III.B.2.a 

III.B.2.b 

& 

Evident 

U1 

R1.2 

Select IMA Application 

III.B.2.a, 

III.B.2.b 

III.B.2.C 

& 

Evident 

U1 

R2 

Modes of Operation 





R2.1 

Test Mode 

III.B.2.a, 

III.B.2.b 

III.B.2.d 

& 

Evident 

U2 

R2.1.1 

Run BIT Test on vehicle and results 
to be displayed on IMA. 

III.B.2.b, 

III.B.2.C 

III.B.2.d 

& 

Evident 

U2 

R2.1.2 

Run FIT Test from both the vehicle 
and IMA. 

III.B.2.b, 

III.B.2.C 

III.B.2.d 

& 

Evident 

U2 

R2.1.3 

IMA maintains knowledge of TP 
numbers and displays results 

III.B.2.b, 

III.B.2.C 

III.B.2.d 

& 

Hidden 

U2 

R2.2 

Look-up Mode 

III.B.2.a, 

III.B.2.b 

III.B.2.C 

& 

Evident 

U2 


Table 2. System Functions 


20 








Ref# 

Function 

Cat. 

Attribute 

Details & Constraints 

Cat. 

Rl.l 

Enter Log-In 

Evident 

Security 

(Boundary Constraint) Log- 

must 


& Password 


access to the 

In and password necessary 





IMA system 

for restricted access. 


R2.1 

Test Mode 

Evident 

Provides for 

(Boundary Constraint) BIT 

must 




BIT and FIT 

test must be run before FIT 





tests 

test. 


R2.1.3 

IMA 

Hidden 

LRU 

(Boundary Constraint) 

must 


maintains 


Monitoring 

Results of BIT and FIT 



knowledge of 



Tests and displays results. 



TP numbers 



Must be reset before other 



and displays 



test can run. 



results 


Programming 

Language 

(Detail) C++ 

must 


Table 3. System Attribute Table 


C. USE CASE DIAGRAM 

The USE case shown in Figure 6 depicts the relationship between the actors (in 
this case the maintenance operator and vehicle system) to the IMA system (Craig Larman 
1997). 



Figure 6. High Level Use Case 
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D. USE CASE SCENARIOS 


1. Use Case 1: Log In 


Use case: 

Log In 

Actors: 

Maintenance Operator (initiators) 

Purpose: 

To log in to SPORT or equivalent computer to access 

IMA System 

Description: 

Maintenance Operator provides password SPORT 

equivalent computer to gain access to the IMA system. 

Type: 

Primary and essential 

Cross-references: 

R1.1,R1.2 


a. Typical Course of Events 


Actor Action 

System Response 


1. SPORT or equivalent computer requests 

Log in and password. 

2. Maintenance Operator enters Log in and 

password into the SPORT or equivalent 

computer. 



3. SPORT or equivalent computer 

accepts/denies Log in and password. 

Brings up start-up screen. 

4. Maintenance operator selects IMA icon 

to start software application. 



5. IMA screen is on and ready to use 
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2. Use Case 2: Run Test 

Use case: Run Test 

Actors: Maintenance Operator (initiators) 

Purpose: To perform Vehicle System BIT and FIT tests. 

Overview: Maintenance operator initiates test by running Built-In-Test (BIT) 

on the Vehicle System diagnostics menu first, then starts the IMA FIT monitor and 
initiate the Fault Isolation Test (FIT) from the Vehicle System diagnostics menu. 

Type: primary, secondary and essential 

Cross-references: R2.1, R2.1.1, R2.1.2, R2.1.3 

a. Typical Course of Events 


Actor Action 

System Response 

1. Maintenance operator initiates BIT test 

from Vehicle System diagnostics menu. 



2. Vehicle System begins BIT. 


3. Vehicle System completes and displays 

BIT results on IMA. 

4. Maintenance operator starts the IMA 

FIT monitor and then initiates FIT test 

from the Vehicle System diagnostics menu. 



5. Vehicle System completes FIT Test and 

displays results on IMA FIT Monitor and 

vehicle. 
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SYSTEM CONTEXT DIAGRAM 
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Figure 7. IMA System Context Diagram 
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Event 

System Response 

Dir. 

Pat. 

Arrival 

Pattern 

Sync 

Pattern 

Enter Log-In and Password. 

SPORT or equivalent 
computer allows 

access to IMA 

application program. 

IN 

Episodic 

Sync 

executeTest(BIT) 

Execute BIT on system 

IN 

Episodic 

Sync 

executeTest (FIT) 

Collects diagnostic 

data from BIT Test to 
pass on to FIT test for 
TP look up table. 

IN 

Episodic 

Sync 

executeTP Look-up (TP) 

Displays results from 
FIT test to TP look up 
table. 

IN 

Episodic 

Sync 

reset (System) 

System must be reset 
to clear previous 

results. 

IN 

Episodic 

Sync 


Table 4. External Events 


Table 4 describes the external events to the IMA system based on events, system 
response, direction pattern, arrival pattern, and sync pattern. 
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F. 


CONCEPTUAL DIAGRAM 



display to initiate run on 



Figure 8. IMA Conceptual Diagram 
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Intelligent Maintenance Aid 

System Sequence Diaijram 


G. SYSTEM SEQUENCE DIAGRAM 



n: Q. 

s: o 


Figure 9. IMA System Sequence Diagram 
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H. GLOSSARY 


Term 

Category 

Comments 

Maintenance 

Operator 

Type 

Personnel responsible for maintaining 

Intelligent Maintenance Aid and associated 

equipment 

Vehicle System 

Type 

Generic term used for describing vehicle 

under test 

Log-In 

Use Case 

Description of operator entering Log-In and 

password data 

Run Test 

Use Case 

Description of operator performing BIT and 

FIT tests 

Display BIT Results: 

Boolean 

Attribute 

Description of GO and NO GO status of 

LRUs. 

Troubleshooting 

Procedure Codes 

(TP): Integer 

Attribute 

Description of errors associated with 

running BIT and FIT tests. 


Table 5. Glossary of Terms 
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IV. SOFTWARE ARCHITECTURE DESIGN 


A. INTRODUCTION FOR EMBEDDED DIAGNOSTICS EOR M1A2 TANK 

Figure 10 presents a high-level view of the Fault Management in a MIA2 Tank 
(GDLS S/SDD 2003). 



Figure 10. Operation and Status of Fault Management 


The System Level Diagnostics is made up of three nested levels: 

• Self Test (ST) 

• Built-In-Test (BIT) 

• Fault Isolation Test (FIT) 


ST is the first level of diagnostics to detect a failure. Upon detection of a failure, 
the crew is made aware of a failure condition via the display mechanism described in the 
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next section. If ST detects a failure or the crew suspects something is malfunctioning, 
further diagnostic testing is essential since ST has limited fault detection coverage due to 
its non-intrusive design. If the tank is in Pre/Post or Combat mode, no further testing is 
permitted until the crew transitions the tank into Diagnostics mode. 

Once in Diagnostics mode, the crew may initiate the execution of Built-In-Test 
(BIT) to confirm a failure detected by ST or a suspected malfunction. BIT’s fault 
detection is more comprehensive because it allows intrusive testing where necessary. 

When ST or BIT detects fault conditions, the tank crew informs organizational 
maintenance of the situation relaying the extent of the failure information provided by ST 
or BIT. Unit maintenance, upon receiving the tank for problem resolution, confirms the 
existence of the fault condition by executing BIT again. If the maintenance crew 
determines that system BIT has isolated to a Line Replaceable Unit (LRU) level, the 
faulty LRU is replaced. If the maintenance crew determines that an LRU ambiguity 
group exists, the maintenance crew initiates Fault Isolation Test (FIT). This either 
resolves the ambiguity or confirms the existence of multiple failures. When BIT and FIT 
fail to isolate the failure to an LRU, the unit mechanic will then resort to manual 
troubleshooting procedures. 

1. Self Test (ST) 

Self-Test is the first level of embedded diagnostics within the M1A2 tank. ST 
reports faults to the crew during all modes of operation. Self-Test data runs in the 
background of each LRU. ST runs upon power-up and performs a health check on the 
system without affecting tank functions. Each LRU, communicating on the bus, provides 
health status to the system. This health status will be interpreted by the system and 
reported to the crew in the form of a caution or warning pop-up on the appropriate 
displays. The 10 LRU’s that make up the tank’s architecture are; 

a. CID 

b. DID 

c. GCDP 

d. HEU 

e. TEU 
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f. POS/NAV 

g. DECU 

h. CITY 

i. FCEU 

j. RIU 


Each of the above 10 LRU’s reports Self-Test data on the health of their own 
system. Self-Test data from each LRU is placed on the 1553 bus through data packet 30. 
Data packet 30 is the reporting mechanism for diagnostic data. Self-Test data is updated 
on the 1553 bus at a IHz rate. When an LRU detects a failure within its internal 
architecture, a bit will be set in data packet 30 from that LRU. Data Packet 30 results 
were evaluated by the bus controller. The TEU applies fault results to the generation 
criteria for Cautions and Warnings. If the TEU fails, the HEU (backup) will take over 
and invoke the Systems Level Diagnostics. If the generation criteria are met, a Caution 
or Warning will be output from the TEU/HEU. The TEU/HEU outputs Caution and 
Warning results on the 1553 bus through data packet 28 (see Figure 11). Data packet 28 
contains the continuous update of all Caution and Warnings and is sent to all three 
displays (CID, DID, and GCDP). Only the Cautions and Warnings that are primary to 
each display will be shown. 


31 




Figure 11. Data Packet Flow 

2. Built-In-Test (BIT) 

Built-In-Test is the second level of embedded diagnostics. BIT is an intrusive test 
of the system health status. BIT operates within the Diagnostic mode of operation and 
performs an intrusive test on various units when commanded by the operator. Once a 
unit is under BIT, it will not communicate within the system until it has completed 
intrusive testing of its internal architecture. The crew can perform a health check of the 
vehicle from all displays. From the Commanders display, the operator can perform a 
system BIT on all units. Once commanded into BIT each unit undergoes an intrusive 
testing of its internal architecture. 

After completion of BIT, the tested units return BIT results, which are displayed 
as GO or NOGO. BIT performed at the driver’s display will report hull-related 
diagnostic BIT results and the gunner’s display will report turret related diagnostic BIT 
status. BIT can also be executed on the fire control system by running the FC SYSTEM 
TEST. The fire control system test can only be run from the GCDP in Operational mode 
with the gunners handle. 
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3. Fault Isolation Test (FIT) 

Fault Isolation Test is the third level of embedded diagnostics. FIT utilizes the 
results from Self-Test and Built-In-Test to reduce ambiguity groups within the system. 
The corresponding ST and BIT results are incorporated into variables. These variables 
make up several hundred Boolean equations to isolate faulty units and generate 
troubleshooting procedure (TP) numbers. 

Maintenance crews can obtain a list of faulty units through Fault Isolation 
Testing. Once the unit is deemed faulty, the crew can replace the unit. 

System Health categories also show up under FIT. System Health category 
contains; 

a. Cable Disconnects 

b. Power Management 

c. Utility Bus 

d. Data Bus Communications 

e. Hull Computer 

f. Turret Computer System 

g. Commanders Station 

h. Drivers Station 

i. Gunners Station 

j. Gun/Turret Drive System 

k. Weapons System 

l. Gun Positioning System 

m. Communications System 

n. Automotive System 

o. Hull System 


Each categories will display a GO or NOGO condition. If a category is a NOGO, 
entering the category will reveal corresponding troubleshooting procedure numbers. 
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B. IMA PROTOTYPE 

The IMA is a PC based application. The application provides two basic 
capabilities: (1) a graphical representation of the real-time 1553 fault reporting, (2) 
HTML hyperlinked troubleshooting procedures for detected failures. To provide these 
capabilities the PC is equipped with a 1553 PCI card, existing TACOM ATE software, 
and maintenance manual documentation in HTML format. The ATE software 
(1553GUI) establishes transmit and receive buffers in the PC shared memory while also 
configuring the SBS 1553 for bus monitoring of desired 1553 remote terminals. The 
IMA connects to the PC shared memory to retrieve real-time remote terminal fault 
information. To provide “on-line” hyperlinked troubleshooting procedures, the IMA 
uses a simple static relational database. Existing maintenance manual documentation 
(pdf format) is converted to HTML. All page or procedure references within all manuals 
are parsed out and stored within the database. All HTML files along with the database 
reside on the local PC. Based on user IMA menu selections and the database, appropriate 
systems manual pages containing the needed troubleshooting procedures are presented. 

C. REAL-TIME FAULT REPORTING 

Remote terminals in the M1A2 system provide real-time fault information in sub¬ 
address (message) number 30 via the 1553 data bus. Refer to Chapter II for the 1553 
protocol description. IMA monitors this real-time data and provides a graphical 
depiction of all fault information via the System Display Window (Figure 12). Fault data 
for particular 1553 remote terminal are accessed by clicking on the desired terminal on 
the System Display Window. For example, selection the CID icon will invoke the CID 
Display Window shown in Figure 13. 
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Figure 12. System Display Window 
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Figure 13. CID Display Window 


D. FAULT DATA 

In the M1A2 system, message 30 information is provided at 1 Hz rate. Message 
30 can contain up to 32 16-bit data words. (Refer to Chapter II for the 1553 protocol 
description.) Specific fault data items for each remote terminal are assigned to a single 
bit within a 16-bit data word. Data words of message 30 are organized in a cascade 
arrangement for each remote terminal. There are three classifications of remote terminal 
faults; Type A, Type B, and Type C. The highest level fault reporting is for the remote 
terminal itself, and these are classified as “Type A” faults. Type A faults are located 
toward the front of message 30. The next level of fault data, “Type B” is assigned to a 
particular components of a remote terminal. Type B faults comprise the middle words of 
message 30. The lowest level items for a particular remote terminal component are 
classified “Type C”. Type C faults are at the end of message 30. “Type C” faults are 
rolled up to comprise the “Type B” faults. In turn, Type B faults are rolled up to 
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comprise the Type A faults. When a low level Type C fault occurs, it in turn sets a 
corresponding Type B fault, which in turn sets the Type A fault. Refer to Figure 14 for 
an example of message 30 structure. 


Data Word 1 



Data Word 2 

Type A 



Data Word 3 


Component 1 


Data Word 4 


Component 2 


Data Word 5 

Type B 

Component 3 


Data Word 6 



Data Word 7 




Data Word 8 



Low Level Component 1 Items 

Data Word 9 



Data Word 10 




Data Word 11 



Low Level Component 2 Items 

Data Word 12 

Type C 



Data Word 13 




Data Word 14 



Low Level Component 3 Items 

Data Word 15 



Data Word 16 




Data Word 17 





Figure 14. Sub-address 30 Organization 

E. GRAPHICAL FAULT CORRELATION 

In the M1A2 system, message 30 data words are enumerated according to the 
1553 vehicle specification. The IMA BIT operations use the information extracted from 
a database table structure as defined in Table 5. Refer to MS Office 2000, or MS Office 
XP for Access database features and operation. 
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Data Field 

Attributes 

Usage 

Field Name 

Data 

Type 

Field 

Size 

Default 

Value 

Required 

Allow 

Zero 

Length 

Indexed 

Unicode 

Compress 

DPNum 

Number 

Integer 


No 


No 


1553 Vehicle 
Protocol 

DPType 

Text 

50 


No 

No 

No 

No 

RT 

Number 

Byte 


No 


No 


SA 

Number 

Byte 


No 


No 


WordNum 

Number 

Integer 


No 


No 


StartBit 

Number 

Integer 


No 


No 


TotalBits 

Number 

Integer 


No 


No 


Owner 

Text 

50 


No 

No 

No 

Yes 

Fault 

Enumeration 

SubOwner 

Text 

30 


No 

No 

No 

Yes 

BIT/RPC 

Text 

10 


No 

No 

No 

No 

Message 

Text 

255 


No 

No 

No 

No 

Status 

Number 

Integer 

0 

No 


No 


Type 

Number 

Integer 

0 

No 


No 



* All other attribute fields blank 


Table 6. IMA Database Structure 

All low level components are traced to the particular remote terminal components. 
The real-time data and database tracing is read, correlated, and presented graphically. 
For example, low level components such a CID 1553 watchdog timer or a CID 1553 real¬ 
time clock fault get traced to the 1553 board component. If either one of these is set, the 
Ml A2 system also sets the Type B 1553 board fault along with the Type A terminal fault 
for the CID. What the IMA user sees graphically on the System Display Window, is a 
text box representation of the last detected detail failure and a RED flag on top of the 
CID icon in the System Display Window (Figure 12). The IMA user then clicks the CID 
icon to display the CID component graphical display. The terminal graphics display, in 
this case CID, is presented in a fashion that represents the terminal as if the real hardware 
box was open (Figure 13). At this component level, the 1553 board would show RED. 
The low level faults, in this case, 1553 watchdog timer or a 1553 real-time clock fault are 
displayed textually. 
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F. FIT SECTION 

The M1A2 system provides a FIT capability. FIT is executed after real-time 
faults have been detected. The M1A2 FIT process correlates documented 
troubleshooting procedures to these real-time faults. The troubleshooting procedures are 
indexed, numbered 1 through n. Based on the faults detected, the FIT outputs one or 
more TP numbers. Each of the troubleshooting procedures is an ordered set of 
instructions, when performed, designed to isolate the possible component(s) responsible 
for the faults detected. 

G. FIT DATA 

Just as with the Graphical Fault Display, IMA connects to the PC shared memory 
to retrieve real-time 1553 TP FIT data. During the M1A2 FIT execution process two 
1553 sub-addresses are used, sub-address 10 and sub-address 11. Refer to Chapter II for 
the 1553 protocol. The M1A2 system monitors sub-address 10 for the user initiation of 
FIT. As FIT executes, TP numbers are output on the 1553 data bus in sub-address 11. 
Each specific procedure index is assigned to a single bit within a 16-bit data word. Refer 
to Figure 15 for an example of the 1553 16-bit FIT data enumeration. 
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SUBADDRESS 11 












Data Word 1 

<0 <0 

Data Word 2 

Data Word 3 

Data Word 4 

Data Word 5 

1000000000100000 

Data Word 6 


Data Word 7 

Data Word 8 


Figure 15. FIT Data Enumeration 

H. IMA FIT GRAPHICS 

IMA reads the real-time FIT data from sub-address 11. IMA then applies bit-wise 
enumerations to extract the corresponding TP indexes. Note that the same MS Access 
database that stores the BIT fault data is used to store these FIT enumerations. After TP 
indexes are gathered IMA populates a GUI sub window with the list of TPs (see Figure 
18). 

Once TPs are gathered, real-time 1553 data is no longer needed. Maintenance 
crew need only follow the step-by-step instructions in the TP to pin point fault sources. 
Instead of requiring the maintenance crew to manually shuffle through procedures in the 
hardcopy manuals, or manually scrolling through electronic pdf files, the IMA provides 
hyperlinked HTML files that can be clicked to display the correct page in the 
maintenance manual. To provide this, the IMA uses a simple static relational database. 
Note that this is the same database that contains BIT and FIT enumerations. To populate 


































the database with needed hyperlink information a series of conversion and parsing was 
necessary, as illustrated in Figure 16. 



Figure 16. Conversion Process 

I. GENERIC HTML CONVERSION 

Existing maintenance manual documentation (pdf format) is converted to HTML. 
An Adobe add-on product, Magellan, is used to parse the pdf maintenance manual 
documentation. The product parsed each pdf page of each manual to a unique HTML 
file. These unique HTML files were assigned names using a convention that including 
the manual volume, section, and page. 
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J. PARSE PDF TEXT REFERENCES 

The same pdf files were also converted to straight text. This allowed text parsing 
for the TP items themselves as well as other internal and external (different manual 
volume) page references. Within each HTML page there could exist many page 
references. This was easily handled with the relational database structure. All page or 
procedure references within all manuals are parsed out and stored within the database. 
TP numbers and page references were correlated to the raw HTML page and to the 
sectional page notation. This correlation data is stored in the MS Access database. For 
all identified references, the HTML file was updated with the hypertext attributes. All 
HTML files along with the database reside on the local PC. The local path is set under 
the File->Preferences menu, shown in Figure 17. 



Figure 17. PDF Text Preference Location 

Based on user IMA menu selections and the database, appropriate systems manual 
pages containing the needed troubleshooting procedures are presented. An illustration of 
the IMA FIT capabilities is shown in Figure 18 below for TP code 333. Clicking on the 
hyperlink for TP333 shown in Figure 18 yields the manual page 3-315 Figure 19. 
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Figure 18. TP Code 333 
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File Edit Status View Window Help _ S' X 






Manual Name Page 

Hull TP Number 

Turret TP Number 

1 ^ 


<3 

m 1 

|TM9-2350-288-20-1-1 |a 

[tpooi 

1 TP 001 




◄ 


► 

TM 9-2350-288-20-1-1 




X Set FIRE EXTINGUISHER 2ND SHOT switch to OFF. 

X Set MASTER POWER switch to OFF. 

X Prepare multimeter for ohms test. 

X Disconnect 2W125-8yP1 from J7 on remote switching 
module 1 f2A102f f paae 3-1006 Y 

X Test for less than 5 ohms between contact B and contacts 
on 2W125-8/P5 listed below: 

xA 

X Connector body 


Does multimeter show less than 5 ohms? 


1 ]_ 

X Set FIRE EXTINGUISHER 2ND SHOT switch to OFF. 

X Replace engine compartment valve and bottle assembly 
(second shot) fpaae 23-21 'I . 

X Verify problem is solved. 



2W125-8/P5 



X Replace branched wiring harness 2W125-8 f paae 9-186) . 
X Verify problem is solved. 


i]_ 

X Connect 2W125-8/P5 to J1 on engine second shot "re 
extinguisher valve f paae 3-10131 

X Replace remote switching module 2A102 f paae 9-72) . 
X Verify problem is solved. 


3-315 


Figure 19. Hyperlink for TPS33 
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V. TEST AND EVALUATION 


No formal testing was conducted during IMA development. The Visual C++ 
Compiler and Debugger tool were used during development. Bug tracking and software 
enhancements were kept informally. At various stages during development, IMA 
modules were tested at the integration level to ensure proper operation of the assembled 
code. After IMA development, the test effort would center on “functional” or “black¬ 
box” testing. “Glass-box” or “white-box” test methods were not employed because of the 
nature of IMA itself. IMA either hyperlinked to proper manual page or it did not. IMA 
either reported the correct system failure that was injected or it did not. Quantitative data 
would be gathered to evaluate IMA usage versus hardcopy manual usage. 


A. TEST GOALS 

The IMA test goals were to validate the IMA fault reporting and to evaluate the 
time it took to trace TPs using hardcopy manuals usage versus the hyperlinked IMA 
manuals. Test goals were to be primarily satisfied by the demonstration method. Data 
will be injected in a controlled environment and IMA will be expected to produce known 
result. With regard to IMA hyperlinking, timing analysis will be used in conjunction 
with the demonstration method. 

1. Interject BIT faults into the M1A2 system 

a. Verify proper IMA top level system flag(s) 

b. Verify proper IMA sub-system flag(s) 

c. Verify proper IMA BIT fault isolation report(s) 

2. Interject FIT faults into the M1A2 system 

a. Verify proper IMA FIT data collection 

b. Verify proper IMA FIT data reporting 

3. IMA troubleshooting procedure hypertext linking 

a. Verify page referencing 

b. Gather timing data for TP tracing using hardcopy manuals usage versus 


the hyperlinked IMA manuals 
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B. IMA TEST SETUP 


IMA is intended for connections to real system hardware. Fault insertions cannot 
be achieved on the vehicle at the lower board level with real system hardware. Specific 
1553 terminal emulations were employed for fault insertions. These were already in 
place in the System Integration Lab (SIL) bench for the M1A2. The M1A2 SIL was the 
environment used for all testing. 

1. IMA BIT Capability 

To verify goals for the IMA BIT capability, two remote terminal configurations 
within the M1A2 SIL were used. In one configuration, the DID terminal was emulated. 
In the other configuration the GCDP terminal was emulated. The complete M1A2 
terminal status for the two distinct test configurations is shown below. The 
corresponding emulation tool appearance can be viewed in Figure 20 and Figure 21. 
a. Simulated DID Configuration 


1553 Device 

Status 

Emulator Appearance (Fig #20) 

HEU 

Actual 

Red Diamond 

TEU 

Actual 

Red Diamond 

DID 

Emulated 

Green Diamond 

CID 

Actual 

Red Diamond 

DECU 

Actual, with 
emulated discrete input 

Red Diamond 

GCDP 

Actual 

Red Diamond 


b. Simulated GCDP M1A2 Configuration 


1553 Device 

Status 

Emulator Appearance (Fig #21) 

HEU 

Actual 

Red Diamond 

TEU 

Actual 

Red Diamond 

DID 

Actual 

Red Diamond 

CID 

Actual 

Red Diamond 

DECU 

Actual, with 
emulated discrete input 

Red Diamond 

GCDP 

Emulated 

Green Diamond 
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2. IMA FIT Capability 

To verify goals for the IMA FIT capability, only one remote terminal 
configuration within the M1A2 SIL was needed. The complete M1A2 terminal status for 
the test configuration is shown below. 


1553 Device 

Status 

Emulator Appearance 

HEU 

Actual 

Red Diamond 

TEU 

Actual 

Red Diamond 

DID 

Actual 

Red Diamond 

CID 

Actual 

Red Diamond 

DECU 

Actual, with 
emulated discrete input 

Red Diamond 

GCDP 

Actual 

Red Diamond 


3. IMA TP Manual Hyperlinking 

To verify goals for the IMA FIT capability, the same remote terminal 
configuration used for the FIT capability was also used for the IMA TP manual 
hyperlinking. 


C. TEST PROCEDURE 

1. IMA BIT Capability 

With the M1A2 SIL running in the configuration described in Section V.B.l.a, a 
known set of BIT faults were injected via the DID emulation. In Sub-address #30 the 
following faults were set (see Figure 20 for the DID emulation): 

• Data word 5, bit 5 (Graphics Board Dynamic RAM) 

• Data word 6, bit 15 (Display Monitor) 

• Data word 4, bit 1 (Graphics Board) 

• Data word 3, bit 0 (DID Selftest Status) 
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File View Help 


System Bend 

I3<> CID 

□♦ss 

00- GCDP 
0O HEU 
□O POS/NAV 
0O DECU 
□O CITV 
□ - FCEU 

□o RIU 


JjJ 


Transmit DP’s 
O 0300 
O 1002 
<> 1202 
<> 1600 
<> 1702 
<> 1900 
<> 2301 
3013 


Receive DP's 
O 0400 
^ 0600 
^ 0800 
^ 0900 
^ 1102 
^ 1502 
^ 1800 
^ 2601 
^ 2802 
^ 2902 


Words Variables | 


Wo... 1 

Variable Description | 

Value 1 

Word Num & Associated Data Word | 

2 

Command Status 

0 

RT Status Word 

3 

DID Selftest Status 

1 

DID Self Test Type 1 

A 

Display 

0 

DID Self Test Type 3 

A 

Power supply 3013 Type 3 

0 

DID Self Test Type 3 

A 

Panel Board 

0 

DID Self Test Type 3 

A 

Graphics Board 

1 

DID Self Test Type 3 

A 

1553 Board 

0 

DID Self Test Type 3 

5 

Panel Board SRAM (limited) 

0 

DID Self Test Type 5 

5 

Panel Board AD/DA Monitor 

0 

DID Self Test Type 5 

5 

Panel Board Software Exce... 

0 

DID Self Test Type 5 

5 

Panel Board Monitor 

0 

DID Self Test Type 5 

5 

Panel Board Temperature 

0 

DID Self Test Type 5 

5 

Panel Board Lamp Driver 

0 

DID Self Test Type 5 

5 

Graphics Board Monitor 

0 

DID Self Test Type 5 

5 

Graphics Board LOCCS 

0 

DID Self Test Type 5 

5 

Graphics Board Software E... 

0 

DID Self Test Type 5 

5 

Graphics Board Video RAM ... 

0 

DID Self Test Type 5 

5 

Graphics Board Dynamic R... 

1 

DID Self Test Type 5 

5 

1553 Board SRAM (limited) 

0 

DID Self Test Type 5 

5 

1553 Board Software Excep... 

0 

DID Self Test Type 5 

5 

1553 Board Watch-Dog Timer 

0 

DID Self Test Type 5 

5 

1553 Board On Line Loop-BK 

0 

DID Self Test Type 5 

5 

Power Supply 3013 Type 5 

0 

DID Self Test Type 5 

6 

Display Monitor 

1 

DID Self Test Type 5 

7 

DID BIT Interactive Test 

0 

DID BIT Type 2 


Range Values 


Increments when data is updated. 


zi 


MlA22.7Drop3RevB [interactive Diagnostics 

[^ 1553 Status Information 

1# SBS10 On/OFF 

r 

Start 1 Test Automation Tool - DI... | 'tj ima FIT DECU.bmp - Paint 

1 Utility Bus Emulator Client 11 15 SYSTEM BENCH 

0lj IMA - system.lru | 

^ 11:47 AM 


Figure 20. Injected BIT Faults For DID 


With the controlled data inputs injected above, the IMA is launched on a PC that 
is also connected to the 1553 system data bus: 

a. Verify on the IMA system.lru window that DID terminal is flagged red. 

b. Verify on the IMA did.lru sub-system window that DID tactical display 
and tactical graphics board are flagged red. 

c. Verify on the IMA system.lru window that, upon clicking the large “Error 
Message Window”, that all injected DID faults can be viewed. These 
appear in a circular scroll list on successive mouse clicks. 

With the controlled data inputs removed: 

d. Verify on the IMA system.lru window that DID terminal is no longer 
flagged red. 

e. Verify on the IMA did.lru sub-system window that DID tactical display 
and tactical graphics board are no longer flagged red. 

f. Verify on the IMA system.lru window that, upon clicking the large “Error 
Message Window”, that no DID faults are viewed. 
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Repeat the procedure above with a known set of BIT faults injected via the GCDP 
emulation. In Sub-address #30 the following faults were set (see Figure 21 for the GCDP 
emulation): 

• Data word 4, bit 0 (1553 Board Type 3) 

• Data word 3, bit 0 (GCDP Selftest Type 1) 

• Data word 5, bit 0 (1553 Board Watch-Dog Timer) 

• Data word 6, bit 15 (1553 Board On Line Loop-Back) 



Figure 21. Injected BIT Faults For GCDP 
With the controlled data inputs injected above: 

a. Verify on the IMA system.lru window that GCDP terminal is flagged red. 

b. Verify on the IMA gcdp.lru sub-system window that GCDP 1553 board is 
flagged red. 


49 





























c. Verify on the IMA system.lru window that, upon clicking the large “Error 
Message Window”, that all injected GCDP faults can be viewed. These 
appear in a circular scroll list on successive mouse clicks. 

With the controlled data inputs removed: 

d. Verify on the IMA system.lru window that GCDP terminal is no longer 
flagged red. 

e. Verify on the IMA gcdp.lru sub-system window that GCDP 1553 board is 
no longer flagged red. 

f. Verify on the IMA system.lru window that, upon clicking the large “Error 
Message Window”, that no GCDP faults are viewed. 

2. IMA FIT Capability 

IMA FIT reporting capabilities were tested using a third test environment where 
DECU faults could be injected. With the M1A2 SIL running in the configuration as 
described in Section V.B.2, DECU emulated engine data for the DECU data was set to 
conflict within the system. Hence, the system recognizes a faulty DECU. The system 
BIT check was run and as expected the DECU appeared as NOGO after the system BIT, 
refer to Figure 22. Faulty equipment must exist for the M1A2 system to output TP 
reference codes during system FIT execution. IMA FIT testing could now be performed. 


‘iY'jrLn \t>\ 

riH . 

VO0C03 i 

-17 31A HOG 0 -10,6/ 

SVSTFH LRUS 



STATUS 

TEU 

NOT TESTED 

GCDP 

NOT TESTED 

FCEU 

NOT TESTED 

Cl TV 

OFF LINE 

RIU 

NOT TESTED 

HEU 

NOT TESTED 

DIO 

NOGO 

OEOJ 

NOOb 

POS/NAV 

NOT TESTED 

DATA BUS 

A NOT TESTED 

DATA BUS 

B NOT TESTED 

UTILITV 

BUS A NOT TESTED 

UTILITY 

BUS B NOT TESTED 

START 

, CANCEL < < '' 


Figure 22. DECU BIT Fail on CID 
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The next step was to execute a system FIT check. Before initiating the FIT check 
with the system hardware, the IMA FIT action was initiated. This kicks off the IMA FIT 
monitoring of Sub-address 30. This extra IMA logic was necessary because system FIT 
data is only valid during FIT execution. Automotive (DECU) related TP codes were 
expected as a result of the FIT check. 

a. Verify the IMA FIT capture logic retrieves TP code information. 

b. Verify that on the IMA FIT Output Window that captured TP codes match 
that reported by the real system hardware. 

3. IMA TP Manual Hypertext Linking 

To evaluate the IMA hypertext linking capability, the same FIT report TP codes 
captured during the DECU FIT reporting validation would be used, TP codes 272, 280, 
and 285. The test method was to have three different subjects navigate through the hard 
copy TP manuals and flag all the pages referenced in each TP tree. The time it took for 
all flags to be put in place were captured to be analyzed. Flagged pages would also be 
compared to the IMA hypertext link to ensure accuracy. The test criteria below was used 
for the test: 

• Three people navigating DECU TP codes in time 

• Flag all page references for the TP navigation (known path) 

• Collect the end times when all flags are set 

D. TEST RESULTS/REPORTING 

The following table summarized all IMA test results. PC screen captures of the 
IMA were saved during testing. These screen captures illustrate the observed results. 
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1 . 


IMA BIT Capability Test Results 


IMA Test Results Table 


Capability 

Criteria 

Reference 

Expected result 

Observed Result 

Comment 

IMA BIT 
reporting 

V.C.l.a- 

DID 

DID terminal is flagged 
red on IMA system.lru 
window when faults 
injected 

As Expected 

See Figure 23 

IMA BIT 
reporting 

V.C.l.b- 

DID 

DID tactical display and 
tactical graphics board 
are flagged red on IMA 
did.lru sub-system 

window when faults 
injected 

As Expected 

See Figure 24 

IMA BIT 
reporting 

V.C.l.c- 

DID 

When injected, all DID 
faults can be viewed by 
clicking the large 
“Error Message 

Window” on the 

system.lru window. 

As Expected 

See Figure 25 

IMA BIT 
reporting 

V.C.l.d- 

DID 

After clearing DID 
faults, DID terminal is 
no longer flagged red on 
IMA system.lru 

window. 

Red DID flag not 
cleared. IMA restart 
was required to clear 
flag on the high level 
system.lru window. 

No code to 
reset/populate 
the internal GUI 
RT flag array for 
the active 

window. 

IMA BIT 
reporting 

V.C.l.e- 

DID 

After clearing DID 
faults, DID tactical 
display and tactical 
graphics board are no 
longer flagged red on 
IMA did.lru sub-system 
window. 

As Expected 

None 

IMA BIT 
reporting 

V.C.l.f- 

DID 

After clearing DID 
faults, no DID faults are 
viewed upon clicking 
the large “Error 

Message Window” on 
the system.lru window. 

All DID faults were 
visible in the same 
circular scroll loop. 

No code to 
reset/clear the 
RT fault array 
stored for 

system.lru 
window. 

IMA BIT 
reporting 

V.C.l.a- 

GCDP 

GCDP terminal is 
flagged red on IMA 
system.lru window 

when faults injected 

As Expected 

See Figure 26 
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Capability 

Criteria 

Reference 

Expected result 

Observed Result 

Couiuieut 

IMA BIT 
reporting 

V.C.l.b- 

GCDP 

GCDP 1553 board is 
flagged red on IMA 
gcdp.lru sub-system 

window when faults 
injected 

As Expected 

See Figure 27 

IMA BIT 
reporting 

V.C.l.c- 

GCDP 

When injected, all 
GCDP faults can be 
viewed by clicking the 
large “Error Message 
Window” on the 

system.lru window. 

As Expected 

See Figure 28 

IMA BIT 
reporting 

V.C.l.d- 

GCDP 

After clearing GCDP 
faults, GCDP terminal is 
no longer flagged red on 
IMA system.lru 

window. 

Red GCDP flag not 
cleared. IMA restart 
was required to clear 
flag on the high level 
system.lru window. 

No code to 
reset/populate 
the internal GUI 
RT flag array for 
the active 

window. 

IMA BIT 
reporting 

V.C.l.e- 

GCDP 

After clearing GCDP 
faults, GCDP 1553 
board is no longer 
flagged red on IMA 
gcdp.lru sub-system 

window. 

As Expected 

None 

IMA BIT 
reporting 

V.C.l.f- 

GCDP 

After clearing GCDP 
faults, no GCDP faults 
are viewed upon 

clicking the large “Error 
Message Window” on 
the system.lru window. 

All GCDP faults were 
visible in the same 
circular scroll loop. 

No code to 
reset/clear the 
RT fault array 
stored for 

system.lru 
window. 
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2. 


IMA FIT Capability Test Results 


Capability 

Criteria 

Reference 

Expected result 

Observed Result 

Comment 

IMA FIT 
reporting 

V.C.2.a 

TP code 

information is 

captured during 

system FIT 

execution. 

As Expected 

TP codes are 
populated in 

the FIT Output 
Window. See 
Figure 29 

IMA FIT 
reporting 

V.C.2.b 

Captured TP codes 
match that reported 
by the real system 
hardware 

IMA reports TP codes 
272, 280, 285, and 
605. The M1A2 

system report for the 
Automotive sub¬ 

system is illustrated in 
Figure 25. TP codes 
are 272, 280, and 285. 
Note that IMA also 
reports TP code 605, 
this is valid because 
the system also 

reported an additional 
cable disconnect TP 
code, 605, under the 
M1A2 

communications sub¬ 
system. 

See Figures 29 
and 30. Both 
IMA and the 
system report 
TP codes 272, 
280, 285, and 
605. 

IMA 

Hypertext 

linking 

V.C.3 

IMA page 

references are 

accurate and IMA 
hypertext linking is 
a faster, reliable 
method for TP 
manual navigation. 

See section 3 below. 

See section 3 
below. 
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3. IMA Hypertext Linking Test Results/Reporting 

Unfortunately, the test subjects that were used were staff engineers; actual vehicle 
maintainers were unavailable for the test. The engineers were familiar with the manuals 
and understood the criteria of the test. 

Each of the engineers was given one of the TP codes to traverse a specified path. 
Engineer 1 had the NO path. Engineer 2 had the YES path and Engineer 3 used the IMA 
with combination of YES and NO decision paths. All of TP codes had an equal number 
decision steps to traverse to ensure a fair test. The results are shown below. 



TP 272 Manual 

TP 280 Manual 

TP 285 IMA 

ENG 1 

6 Min 32 Sec 



ENG 2 


6 Min 56 Sec 


ENG 3 



20 Sec 


This by no means a scientific sample of data but it does suggest that the 
hyperlinked TMs are more maneuverable than the paper manuals. Whether the 
maintainers would have performed better than the engineers is speculative at this time. 

4. Problem with System Buffer Reset 

We found a design flaw in the IMA at this part of the test. The system buffer 
could not be reset. So to run successive tests we would have to reboot the IMA system 
each time. This will be addressed in the next version of the software. 

Low-level BIT fault reporting is not visible to the M1A2 system displays. An 
external 1553 bus monitor was connected on the 1553 bus to allow monitoring of the 
Sub-address #30 fault data words for each 1553 terminal (shown in Figure 22 and Figure 
23). 
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Figure 23. DID BIT Results on IMA 

Fault in this message were compared to the faults reported via the IMA for 
validation (shown in Figure 24 and Figure 25 below). 



Figure 24. DID BIT Sub-system Results on IMA 
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Graphics Board Dynamic RAM 
Display Monitor 

Graphics Board 

DID Selftest Status 

Figure 25. DID BIT Reports from IMA 

In addition, IMA had identified the specific board failure in each fault injected 
LRU (shown in Figure 26 and Figure 27) below. 



Figure 26. GCDP BIT Results on IMA 
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Figure 27. GCDP BIT Sub-system Results on IMA 


1553 Board Type 3 


GCDP Selftest Type 1 


1553 Board Watch-Dog Timer 


1553 Board On Line Loop-BK 


Figure 28. GCDP BIT Reports from IMA 
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Figure 29. DECU FIT Results on CID 



Figure 30. DECU IMA FIT Results 
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E. TP MANUAL USAGE 

To evaluate hardcopy manual usage, the same FIT report TP codes captured 
during the DECU FIT reporting validation were used. The test criteria below were used 
for the test: 

• Three people navigating DECU TP codes in time 

• Flag all page references for the TP navigation (known path) 

• Collect the end times when all flags are set 

Unfortunately, the test subjects were staff engineers; actual vehicle maintainers 
were unavailable for the test. The engineers were familiar with the manuals and 
understood the criteria of the test (refer to Section V.A item 3 and Section V.C item 3). 
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VI. CONCLUSION 


In designing and building the IMA, we attempted to provide the end user (the 
maintainer in our case), with a diagnostic tool that went beyond what was provided by the 
Technical Manuals (TMs). By utilizing the M1A2 diagnostics capability in conjunction 
with an enhanced electronic version of the TMs, the IMA would arm the maintainer with 
a new arsenal of tools to increase his capability to reduce time in diagnosing vehicles. 
The key thrust in the development of the IMA was to reduce or eliminate technical 
manuals in print, reducing possibly of mix-ups, lost pages, and reducing update costs. 
One of the key elements in the design was not to increase the logistics burden to the 
program manager, therefore, the use of the SPORT software downloader was chosen, as 
it was already part of the inventory. 


A. LESSONS LEARNED 

The lesson learned during development of the IMA was requirements creep. 
Throughout the requirement and design phase of this thesis project, management of, if 
you will, “the bells and whistles” became paramount. We wanted to provide the 
maintainer as many tools as possible while keeping in mind the scale of project. With 
this said, we had to tone down what to include in this phase of development. The end 
result is a set of advanced tools that presents the user/maintainer greater flexibility and 
insight into 1553 data bus message passing and diagnostics. 

Having the actual maintainers perform the diagnostic tests from start to finish 
would have been the ideal test environment to prove paper versus computer. Due to the 
war effort, finding qualified maintainers to participate in a master’s thesis research was 
impossible. 

It is the author’s sincere hope that further research time will be given to pursue 
and convince the program management office that the IMA is a useful and timesaving 
device. 
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B. FOLLOW ON WORK 

1. Pre-Planned Product Improvement 

Once the IMA has proven its capabilities and value to the Army maintenance and 
support activities we can further investigate and exploit the technology that is available 
from commercial industry to further enhance IMA capabilities. Further areas of interest 
would be prognostics, Maintenance Knowledge Database (MKD) and automated 
preventive maintenance activities. COTS software packages such as Prognostic 
Framework will be investigated and leveraged to enhance system capabilities. Adding 
prognostie capability will preempt component failures and improve the vehicle’s 
readiness. Implementing a MKD will provide various types of information sueh as 
vehicle repair history and access to the fleet vehicle repairs that are similar to the 
diagnosed problem. The MKD will also provide repairs with tips and methods from 
other Army technieians. It will also have the capability to order the parts needed for the 
repair and list the parts that were ordered in the past to fix similar problems. The 
automated preventative maintenance will schedule, maintain, and track a vehicle’s usage 
through system logs and by the types of mission the vehicles are being sent on. 

2. Removing the System Buffer Reset Problem 

Further development of the IMA must include reset for the system buffer. As we 
encountered during the testing phase when injecting the faults and running BIT and FIT 
tests the resulting TP codes were in the system buffer with no way to clear them. The 
only method was to re-boot the IMA system and start process again. 
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